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A server agent system that provides agents, transmitted to a 
server by a client, that monitor specific event(s) on the 
server. When a pre-defined event(s) occurs, an agent per- 
forms a set action(s) in response to each event. The actions 
are predefined by the client. The agent requires no further 
intervention of the client once it is placed on the server and 
are created by a client or news reader and, when created by 
a news reader, agents are treated as a value added service 
provided by the application. The types of actions that an 
agent performs can be almost anything that the client desires 
and include the execution of Java and/or Javascript pro- 
grams which are supplied by the client or the server. An 
agent's events and actions are subject to the same access 
control security restrictions as the client that submitted the 
agent. The types of agents available on a server are pre- 
defined and are supplied as agent templates and are building 
blocks for the client to build agents with. A server can only 
supply agents that it understands and publishes the available 
agent templates and events on an agent home page where 
clients select from the list of agent types available on the 
server and submit an agent to the server. Servers also 
provide administration services for clients with resident 
agents where they monitor and manage their agents on the 
server. Each agent is assigned a unique identifier and token 
by the server. Names can also be assigned to an agent by the 
client. Server administrators are provided with an adminis- 
tration function to maintain and manage agents resident on 
that server. Agent objects are created on the server that 
uniquely identify that agent which is mapped to the proper 
event and is triggered upon occurrence of that event. When 
the agent is triggered, its action list is processed, executed 
and agent information and statistics are logged. 
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SERVER AGENT SYSTEM 

This application claims the benefit of Provisional Appli- 
cation No. 60/086.996 filed May 28. 1998. 

5 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The invention relates to client-server interaction in a 
computer environment. More particularly, the invention 
relates to the creation and operation of agents for asynchro- 
nous client-server transactions in a computer environment. 

2. Description of the Prior Art 

Webserver users have had difficulty with keeping track of 
the contents of a webserver Currently, if a user is waiting for 
updates to a document on a website, then he must periodi- 
cally visit the website (hosted on a webserver(s)) to examine 
the document. There is no automatic method for letting a 
user know when a document is updated. This forces users to 
frequently visit servers which causes increased network 
traffic, higher loads on the server, slower response times, and 
inconvenience to the users. 

Additionally, users sometimes require periodic reminders 
or need to perform certain tasks periodically, e.g., sending an 
email to someone on their birthday. User tasks may be 
highly time critical. Web Servers currently have no way of 
performing such tasks. This is because a Web Server is 
passive and performs tasks only when a user is connected to 
it. 

30 

None of the current Web Servers have solved this problem 
elegantly. They require the user to periodically poll a web- 
site. This places the burden on the user to remember 
important dates and, if the user forgets a date, he will miss 
the important tasks associated with that date. As mentioned 
above, the current approaches cause an increase in network 
traffic, higher loads on the Web Server, and have no way to 
automate routine tasks. 

It would be advantageous to provide a server agent system 
that intelligently monitors a server for certain events. It 40 
would further be advantageous to provide a server agent 
system that allows a client to easily create an agent that 
performs operations specified by the client in response to 
these events without any further involvement from the 
client. 45 

SUMMARY OF THE INVENTION 

The invention provides a server agent system. The system 
asynchronously monitors events that occur on a server that 
are specified by a client. The server performs actions in 
response these specific events. In addition, the invention 
provides a system that allows the user to easily create and 
maintain the agents that perform the monitoring services. 

A preferred embodiment of the invention provides agents, 
transmitted to a server by a cUent, that monitor specific 
event(s) on the server. When a pre-defined event(s) occurs, 
an agent performs a set action(s) in response to each event. 
The actions are pre-defined by the client. 

The agent requires no further intervention of the client 
once it is placed on the server. The type of events that an 
agent can perform are specified by the host server. 

Agents are created by a client or news reader When 
created by a news reader, agents are treated as a value added 
service provided by the application. 55 

The types of actions that an agent performs can be almost 
anything that the client desires and include the execution of 
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Java and/or Javascript programs. The Java and/or Javascript 
programs are supplied by the client or the server An agent's 
events and actions are subject to the same access control and 
security restrictions as the client that submitted the agent. 

Email is used to send notifications from a server to a 
client, confirming that an agent submitted by a client to the 
server was received. The email facilities are diverse such 
that the client can also specify that an email notification be 
sent to a group of clients. Email notification is also used by 
servers to notify a client that an agent has expired. 

The types of agents available on a server are pre-defined. 
These pre-defined agents are supplied as agent templates and 
are building blocks for the client to build agents with. A 
server can only supply agents that it understands. Servers 
publish the available agent templates and events on an agent 
home page. Clients select from the list of agent types 
available on the server and submit an agent to the server. 

Servers also provide administration services for clients 
with resident agents. Clients monitor and manage their 
agents on each server Each agent is assigned a unique 
identifier and token by the server Names can also be 
assigned to an agent by the client. Server administrators are 
provided with an administration function to maintain and 
manage agents resident on that server 

Agent objects are created on the server with a unique 
identify. The agent is then mapped to the proper event and 
is triggered upon occurrence of that event. When the agent 
is triggered, its action list is processed. The actions are 
executed and agent information and statistics are logged. 

Other aspects and advantages of the invention will 
become apparent from the following detailed description in 
combination with the accompanying drawings, illustrating, 
by way of example, the principles of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is block schematic diagram of the client-server 
interaction over a computer network according to the inven- 
tion; 

FIG. 2 is a block schematic diagram of a server perform- 
ing an action in response to an event according to the 
invention; and 

FIG. 3 is a block schematic diagram of a task-oriented 
view of a preferred embodiment of the invention according 
to the invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The invention is embodied in a server agent system in a 
computer enviromnent. A system according to the invention 
provides a method for asynchronous transactions between a 
server and a client. In addition, the invention provides a 
system that allows the user to easily create and monitor 
agents performing the asynchronous transactions. 

Referring to FIG. 1, a preferred embodiment of the 
invention aUows a client 101 to create and monitor agents 
placed on server 105 across a computer network 104 such as 
the Internet or an intranet. These agents monitor specific 
asynchronous events on a server 105 and perform user 
specified tasks in response to these events, e.g., e-raailing a 
reminder message to the client on a certain date. 

A client can only view documents on a server across a 
computer network using traditional server products. The 
server provides services only as long as the client is con- 
nected to the server In other words, the client-server trans- 
actions are synchronous. However, in many situations, it 
would be desirable to have an asynchronous server response. 
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It would be very helpful if the server could notify (using 
some mechanism) the client upon occurrence of an event. 
For example, a dicat can request notmcation from a library 
(server) when a specific book is available for checkout or a 
client can request a phone call from an airline ticket server 
when a seat becomes available on a particular flight. These 
are examples where the response from the server is asyn- 
chronous. There are two distinct phases in this scenario: 

1. A client requests that the server perform some actions 
when a specific event occurs; and 

2. The server keeps track of the cUent's request and 
performs the actions when the event occurs. 

In general, there is an event and an associated action(s). 
A main feature of the invention is that, after the client 
requests the server to monitor events and execute actions, 
the server takes over the responsibility of ensuring service. 
The client does not have to remain connected to the server. 

The event/action combination is called an agent object. 
The server monitors events and triggers the actions when the 
desired event occurs, on behalf of the dient. In other words, 
the server acts as an agent of the client with respect to the 
event/action, 

A client creates agent objects and hands them over to the 
server. The event/action combination resides on the server as 
an agent of the client. An agent object provides service to the 
client but the agent is managed, monitored, and controlled 
by the server. The term server side agent is also used to 
describe an agent. 

The term "agent" is highly overloaded. There are different 
meanings attached to it. Autonomous agents are programs 
that travel between sites, deciding by themselves when to 
move and what to do. These can only travel between special 
servers and are currently not widespread in the Intemet. 

Intelligent agents are programs that help users with 
things, such as choosing a product, or guiding a user through 
form filling, or even helping users find things. These have 
generally httle to do with networking. 

Much of the work with agents is in the artificial intelli- 
gence area (learning agents) which do not have anything to 
do with Web agents. Web agents are small entities that allow 
a client to specify actions to a server that must be executed 
in response to an event. 

Agents are also viewed as mobile programs that move 
from machine to machine, gathering/learning information. 
An agent is also seen as a small program that works on huge 
amounts of data. Instead of moving the data from different 
locations to the agent site, the program moves to the data 
site. The cost of moving the program (agent) from one site 
to another is trivial. This is the rationale behind web 
crawlers. A typical example is an agent that moves from one 
site to another looking for the best deal on a vacation 
package. 

An agent as used in this document is an object that 
contains an event and actio n(s). Both events and actions can 
be implemented as complex programs. What an agent can do 
is completely up to the programmer implementing it. 

The invention provides the necessary tools to manage 
agents fi-om the client side. Agents are described in this 
document as objects that require services from the server but 
are created by clients. In other words, the agent is interested 
in things (events) happening on the serve r(s) and it executes 
on behalf of the client on the server. 

One skilled in the art will readily appreciate that although 
the description herein focuses on agents on the server side, 
agents can also reside on the client side and be defined by a 
server or possibly another client. 
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Anatomy of an Agent 

As described above, an agent object has two parts — an 
event and a set of actions. An event is something that triggers 
the actions. It could be as simple as a specific time (e.g., 
5 Monday, Mar. 4, 1996 at 9 AM) or a logical combination of 
things (e.g., seat on flight X is available, and a seat on the 
connecting flight Y is also available, and accommodation in 
hotel H is available). 

An event can also be a recurring event (e.g., every 
alternate Tuesday at 6:30 PM). Such recurring events could 
lead to an agent that never terminates (i.e., it can only 
terminate when the client who created it requests to do so). 
Ideally, any type of event that a client is interested in is 
supported. 

An action, or a set of actions, is anything that a client 
wishes to do when the specific event occurs. The action can 
be as simple as sending an email message to the client or it 
can be a series of actions (e.g., make reservations on flight 
X and Y, book a room in hotel H, book a car with Speedy car 
rental, send a message to friend F asking for a ride to airport, 

20 send a message to newspaper agency asking them to suspend 
delivery of paper, etc.). An action can involve the placing of 
a telephone (or pager) call to the dient informing him that 
fiinds have been deposited into his Swiss bank account. A 
more complex action can ask the server to execute a Java 

25 program (or a JavaScript script) that was submitted by the 
client when the agent object was created. 

Agents are not guaranteed to get triggered some time in 
the future when they are submitted. It is possible that the 
event that the agent is waiting on will never occur. For 
example, if an agent is waiting on modifications to a file, but 
the file is deleted, then the event can no longer happen. This 
causes the expiry of the agent (abnormal termination). The 
owner of the agent receives a notification indicating such 
failures. 

Creating Agents 

Clients need a way to specify events and actions. Creating 
an agent involves the specification of the event and the 
associated action(s). This is like writing a small program that 
checks for events. A set of standard agent templates is 
provided by the invention that clients can use with little or 
no modifications. For example, an agent that monitors 
changes to a Web page is a standard template. An agent that 
gets triggered on a time event is another standard template. 
In most cases, clients modify these template agents and are 
done with it. 

FaciUties are also provided by the invention to create 
sophisticated agents for those clients whose needs are not 
met by the template agents. 

The next step is that of transferring the agent object to the 
server. Once the agent object has been successfully trans- 
ferred (or transmitted) to the server and validated by the 
server, the client can rest assured that the requested service 
will be done (except in cases where some catastrophic event 
prevents the server from fulfilling its responsibilities). Note 
that a server crash does not imply the loss of agent objects 
because agent objects are persistent. 
Types of Events 

An agent can be triggered by different types of events. 
Some are simple time events and others are complex events 
generated by relational databases. The foUowing is an 
example of a fist of possible event types: 

Time related Events 

Trigger at a specific date and time. 

Trigger periodically (recurring event). 
65 Trigger if the date is X and day is Y. 

Trigger if the date is X, day is Y and it is an even (or odd) 
month. 
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Document related events 

A new document of a certain type is created on the server. 
A new version of a specific document is created on the 
server. 

A new document by a certain user is created. 5 

A document is deleted. 

A document is moved or renamed. 

A specific document is modified on the server. 

A specific document is accessed by a certain \iser. 

A specific user accesses any document on the server. 

A specific user modifies a document on the server. 

A document of a specific type is created on the server. 

Administration events 

These agents are useful to administrators of servers. An 
agent can look for access by a specific user, a specific 
user disconnecting, low disk space, log file size, etc. 
Server writers and server administrators provide ways 
to detect events. Users are allowed to register for events 
published by the server. Server administrators (who 20 
have full control over the server) are free to add and 
publish new events. 

Program detected events 

A sophisticated user might submit a Java/JavaScript pro- 
gram to detect events and trigger the agent. Again, a 25 
user would not be allowed to submit any Java program 
as part of an agent. Servers provide specific Java/ 
JavaScript programs that clients can use in their agents. 
The available set of such Java/JavaScript programs are 
determined by the server administrator. 30 
In general, clients have the capability to detect any event, 
subject to authorization and access control. The agent frame- 
work provides direct services to detect events or the fi-ame- 
work enables service access points that chents can use to 
detect interesting events by writing Java/Javascript pro- 35 
grams. Agents can only register for events published by a 
server. Clients are not able to register for any arbitrary 
events. This is because every server provides a different kind 
of service and the server writers decide which events are 
available from their server(s). 40 

Every server that allows agents to run, publishes the 
complete set of events that an agent can use. This makes it 
possible for server administrators to have full control over 
what events are detectable by agents. The types of events 
that are made available are only limited by the server writer 45 
and not the agent framework. The agent framework, by 
default, provides a basic set of events that are most common 
among servers (such as those described above). 

With respect to FIG. 2, clients can specify a combination 
of any of these events. For example, a client 201 can specify 50 
"if document A is modified before Jan. 1, 1997 send me 
mail." When the event 206 occurs, i.e., document A has been 
modified before Jan. 1, 1997, the agent then causes the 
server 205 to send an email message 207 to the client 201. 
The client could have also specified that email messages 55 
208, 209, 210 be sent to several clients 202, 203, 204. 
Types of Actions 

This is really up to the client's imagination, because a 
client can write a Java/JavaScript program to do whatever 
they want (subject to access control). But for most clients, at 
the minimum, the foQowing examples of types of actions 
should be provided: 

Send a mail message to a specified user(s) with specified 
contents. 

Initiate a telephone call, page, (or send a fax) to a specific 65 
user (assuming that the server has access to telephone/ 
fax). 
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Post a new message on a newsgroup. 

Log an entry in a database (or a log file). 

Post to a web page. 

Send a HTTP notification. 

Submit another agent to run on the server. 

Execute a server supplied Java/JavaScript program when 

triggered, 
SNMP actions. 

Sending an email message, fax, page, etc., all require 
similar Application Programming Interfaces (API) on the 
server. 

As with events, clients can do anything in response to a 
trigger. The agent framework provides services that clients 
can use to do anything they prefer. 

The available set of actions on a server is controlled by the 
server writer/administrator. An agent can only perform those 
actions that are supported by the server. The agent frame- 
work provides the necessary API for server writers to 
implement their specific actions. Most general actions (like 
sending a mail message, posting to a web page) are part of 
the base agent framework. 
Managing Agents — the Client's View 

Once agents are created and transferred to a server, 
facilities are needed to control them (disable, remove, copy, 
list, etc.). A client may wish to review the list of all agents 
created by him. Siniilarly, on the server side, facilities are 
needed to manage all of the agents resident on that server. 
The following paragraphs focus on the client's perspective. 
Creating Agents 

Every server supports a pre-defined set of agent types 
called agent templates. They are analogous to a class in any 
object-oriented language. Clients must create an instance of 
one of the templates and submit it to the server. Any instance 
of an agent submitted by a client runs on the server on behalf 
of the client. To make this easy, every server supporting 
agent services provides an agent home page. 

The agent home page describes all of the different agent 
templates available on that server and is basically a forms 
interface. Complete details of every agent template is avail- 
able (including textual description) in this page. Clients can 
navigate this page, create an instance of one of the agent 
templates and submit it to the server. To further ease the 
process of creating agent instances, a server can group the 
agent templates into different categories (document related, 
time related, SNMP related, operating-system related, data- 
base related, etc.). Clients can navigate the hierarchical list 
of agent templates. 
Creating Context-sensitive Agents 

Some clients might not go to the agent home page to 
create agents. Consider a news server that supports agent 
services. A client can create an agent that will notify the 
client when a new article is added to a particular thread in 
a specific newsgroup. The client may not know anything 
about the home page. 

To facilitate application specific (or context specific) 
agents, the Meta (or services) menu in a Web browser can be 
used. The Meta menu is used for accessing document meta 
information. Agents are treated as a meta facility (a value 
added service provided by the application) that document 
writers might support. 

For example, the news reader would add a menu item in 
the Meta menu that allows the client to create an agent as 
mentioned above. By selecting this menu option, the appli- 
cation (news reader) creates an instance of an agent template 
and submits it to the server (after confirmation by the client). 
This enables clients to submit agents in the context of their 
application. 
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Application writers are expected to make use of this Look at the statistics of an agent 

facility extensively. It is assumed that, sooner or later, most Clients that do not remember (or do not have access to) 

of the agents v.'il! be created this way. This also allows the agent id returaed by the server, can use this mechanism 

content providers to offer agent services without the clients to enumerate all of their agents. Even though this is a bit 

doing or knowing anything about agents. 5 tedious for clients who have submitted numerous agents, it 

Agent Editing provides another way of accessing agent information. 

As with anything else in software, it is not good enough Agent Management 
to be able to create agents. Facilities for modifying and . , ^^^^"^ "-^^^ ^^.^^^ ^.^ ^h^ agents submitted by 

saving agents are also needed. For example, a client might ^^^"^ °° ^ ^^^^ "^^^^y ^^e client to remove 

° 4 ^: * -c «• *■ « an agent, suspend an agent, and enable an agent. When the 

create an agent for notification at a specific meetme tune. lO . . • f ^ * n • u * 

, , . ^ . . , , , . T- T. agent object is suspended, it still remains on the server but 

But later he might want to change hat notifica ion tune. It -^.^ ^^^^^ ^-^ -^^^^ j-^^^^- ^^^^^^y ^^^^^ ^^^^^ 

should be possible to name agents (an agent id) so that the ^^^^ ^^^^^ ^^^^^ triggered. Such 

name can be used by a chent to identify the agent. The dormant agents can be re-enabled and they become normal 

naming scheme uses the client's name and server name to agents 

make the agent ids unique across client-server pairs (tuples), is when an agent is removed, the server no longer knows 

This is one type of agent editing where an existing agent is anything about that agent object. It is physically removed 

modified and resubmitted. (deleted) from the list of agents on the server. When (re) 

aients may also want to save a copy of an agent before viewing agents, all relevant information about the agent 

submitting to the server. For example, a client may create (date/time submitted, number of times activated, date/time 

time notification agents for different times. Instead of going 20 last modified, etc.) is available, 

through the operation many times, he could just create one Managing Agents— Server View 

agent, make copies of it, modify the time component, and Managing agents on the server is complicated. The server 

submit them to the server. takes care of agent object persistence, agent information 

Any client submitting an agent receives a confirmation logging, enor recovery in case of server failure, authenti- 

aboul the agent submission from the server via email In 25 cation of agent object, etc. 

other words, a client must have an email address to use agent ^^^?} ^^i^^^ Persistence 

services. The mail message provides details about the name ^ ^^en an agent submitted by a client is acUve on a server, 

of the agent (agent identification), time created, etc. Clients f ^^^^ ^^e action will be perforated. But 

. • Ml'*/ I au \ . l ji I. what happens when the server crashes due to some condiUon 

must use their mail clients (mail filters) to handle such . . , . u *u j • • * * \o «n. *t- 

„ . ^ ^ ^ (or what if It IS shutdown by the admimstrator)? When the 

connrmations. . • ^ , server is restarted, all agents that were active just before the 

E-mail IS used as the communication channel to ensure ^^^^^ ^^^^^^^ ^^^^ reactivated. This requires that the 

site mdependence and mobility. Users can access detads ^^ate of the agent be persistent. To recover agents from 

about their agents from anywhere, provided they have access ^^^j. cashes and such catastrophic events, the architecture 

to their email accounts. A client submitting an agent may vvill implement checksum and other error recovery schemes 

also specify that the confirmation be sent to an entire group, 35 to guarantee agent persistence. 

If the confirmation message sent by the server is lost, then Agent Activity Logging 

the user must submit another agent. Loss of the confirmation Servers log all important information about agent objects, 

message does not imply that the agent itself was not The information includes the time when the agent object was 

accepted by the server. It just indicates that the client did not submitted, time when the agent object was triggered due to 

receive the confirmation put out by the server. 40 an event, number of times the agent was triggered (in case 

Clients can pick any name they like for their agents. The of recurring event agents), etc. In addition, general infor- 

server generates a unique id for each agent submitted mation like the total number of agents submitted, number of 

(somewhat like a URI). This agent id is sent to the client in agents that were triggered, number of agents that were 

the confirmation message mentioned above. Clients must deleted by clients, number of agents that expired, etc. are 

use this id when they talk to the server regarding the agent. 45 also available. 

The agent id will contain details about the agent (time/ Agent Management 

date created, usename, user address, etc.). The intention here The issues surrounding agent management on the server 

is to map the agent id to a page on the server. A client is able side are quite similar to those on the dient side. The server 

to click on an agent id, bring up the information about the administrator should be able to suspend, enable, and termi- 

agent, and edit it. This makes the entire browser interface to 50 nate an agent. In all such cases, the originator of the agent 

agents uniform (clickable objects). should receive a notification about the operation with 

Clients are able to control/review the following data: enough explanation of the action. For example, the agent 

List of available agent classes (or categories) iriay be terminated because it was consuming more 

r ' , r . ■ . 4 4 A' resources (dLsk, memory, etc.) than allowed. 

List of agent instances outstanding „ ^, ' , ,1 . • . 

Bv user Servers should be allowed to impose limits on the number 

n / u- * 4^ ♦u \ of agents that can be active at any time on the server, the 

By user group (subject to authentication) t ^ , • . . . 

T, • 4- / u* ♦ » .u \ number of agents per client that can be active, resource 

By organization (subject to authentication) . ^ vt . . . t . . 

Bv aeent class limits on agents, etc. Note that there might be a large number 

^ , ^ , . , of agent objects that were submitted to a server but not all 

List of agents that were triggered ^j^^^ ^ ^^^^^ 

y user ^ • • v Servers may also impose limits on the quality of service 

By user group (subject to authentication) ^^ ^^^^ j ^^^^^ ^^^^^ 

By organization (subject to authentication) granularity is limited to five minutes. All these limiu are 

y agen c ass configurable on a per server basis (server administration). 

Delete an agent ^5 Server administrators have full control over agent aclivi- 

Suspend an agent (not the same as deleting) ties on their servers. In addition to what a normal client can 

Resubmit an agent do (as mentioned above), a server administrator can: 
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View all agents on the server 
By user 

Rv stat"!^ reYm'reH tncropreH waitinQ to triiiQer. deleted 
by user) 

By agent template class to which the agent belongs 

By creation time 
Delete, modify, and Suspend any agent 
Restrict the activities of an agent 
Restrict agents of a class 

By user 

By group 

By domain 

All 

Disable/Suspend agent submissions by 
By user 
By group 
By domain 
AU 

Limit number of agents created 
By user 
By group 
By domain 
All 

Force manual triggering of agents 
Agent Naming 

Just creating agents is not good without a way to name 
them. Both clients and servers need a naming facility. A 
client might ask a server(s) to terminate an agent by name. 
Similarly, the server migiit send a notification to the dient 
indicating the expiration of an agent. Agent names, as 
mentioned earlier, are very similar to URIs. 
Security and Access Control Issues 

Access control and security must be enforced with all 
aspects of agent activities. Agents submitted by clients are 
subject to access control on the server side. An agent is not 
allowed to access anything that the client who created the 
agent cannot access. This is probably the hardest thing to 
enforce. It is even more di£5cult with Java and JavaScript 
agents. There are many issues involved here. 

Access control must be enforced on what event an agent 
can register for and what actions it can perform. This is 
verified before the agent is accepted by the server whenever 
possible. The agent is not allowed into the server if the 
access control checks on the events and/or the actions fail. 
Access control is also enforced with respect to agent cre- 
ation and agent deletion. Not all clients arc allowed to 
submit agents to a server. Similarly, an agent can be deleted 
only by authorized personnel. All such operations are sub- 
ject to strict access control. 

Even with all of the checks on access control, there is no 
guarantee that an agent will execute to completion when the 
event is triggered. Due to the dynamically changing nature 
of servers and the internet environment, the agent might fail 
access control checks when it executes due to the triggering 
of an event. The client is notified about such failures with the 
appropriate explanation. 

Access control is also enforced with respect to viewing 
agents on a server. Clients are not allowed to view, let alone 
delete/modify, agents created by others unless they have 
been authorized to do so. 

Server administrators are not able to examine agent 
objects unless they have been authorized to do so. An 
administrator is able to administer (enable, disable, etc.) 
agent objects on the server but he is not able to look into the 
events or actions contained in the agent. 

If an agent instance is implemented as a URL, then 
security and access control are available for free. 
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When an agent is triggered, the specified action is per- 
formed. If the action involves sending a mail message to 
some address, the mail message will identify the creator of 
the agent (the client that submitted the agent) that caused the 

5 message to be sent. 

Server API for Agent Development 

As with any other server feature, programmers would like 
to write their own code to do wonderful things with agents. 
APIs are provided for agent programmers to harness the 

10 agent capabilities in a server. 
Design of the Agent Subsystem 

The primary design goal was to keep the agent subsystem 
independent of any server services. In other words, the agent 
subsystem should be completely decoupled from the par- 
is licular type of server. This is done to ensure that agent 
services can be used by any Netscape (or even third party) 
server or any other application requiring agent services. To 
achieve this goal, the agent subsystem is separated into 
distinct, replaceable components. The high level architecture 

20 diagram is shown in FIG. 3, 

Agent Controller (AC) Component 305 

The AC 305 is the heart of the system. It manages all 
aspects of agent creation, destruction, statistics update, per- 
sistent storage, and parts of agent administration. Any pro- 

25 gram (or client) that wishes to create an agent must use the 
API of this component. 

Every agent has a unique identification number 
(AgendID). Agent ids are unique within a server but not 
aaoss servers. These agent ids are generated by the agent 

30 controller component. 

Server and application developers who want to use agent 
services must program to the API of the AC 305. The HTTP 
Server Liaison component 301 provides the necessary UI to 
create and manage agents. 

35 Agent Classes and Agent Objects 

The concept of an agent class and an agent instance to 
control agent name space growth has been previously intro- 
duced. As an example, consider an agent (created by user 
John) that waits on the document http://warp/foo.htm. 

40 Assume that the agent is interested in the event "Document 
Checked out." The event type for checkout is 105 in this 
example. The combination "http://warp.foo. htm+105" is a 
unique token. This token identifies an agent class. At this 
time, there is only one instance (or object) of this agent class: 

45 

Agent class identifier Number of instances 



http://warp.foo.htm + 105 — » 1 (User John) 

Next, user Smith wishes to create an agent object to look 
for checkouts of http://warp.foo.htm. At this point, there is 
already an agent object waiting on this document for the 
same event type. Therefore, the agent class is already in 
existence and a new object of this agent class must be 
created: 

Agent class name Number of instances 



http://warp.foo.him + 105 — > 2(User John, User Smith) 

60 

Now consider the scenario where a user Jane wants to 
create an agent for document http://warp.foo.htm but she 
wants to be notified when the document is deleted (event 
65 type 106). The combination "http://warp.foo.htm+106" is 
another agent class name. The agent event processor 306 
recognizes that this agent class doesn*t exist and hence 
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creates the agent class "http://warp.foo, htm+ 106" and also 
creates the first object of this class for user Jane. 



Agent class name 



Number of instances 



httpVAvarp.foo.htm 4-105 — » 
http:/Avarp.foo.htm -t- 106 —* 



2CUser John, User Smith) 
KUser Jane) 



If another user Jack wants to be notified at "Thu Aug 15, 
96 10:00 AM," another agent class is created. Assume that 
the timer alarm has an event type 222, then: 



Agent class name 



Number of instances 



http://warp.foo.hlm + 105 — * 
htq)://warp.foo.htm + 106 — * 
Thu Aug 15. 96 10:00 AM 4- 222 — > 



2(User John, User Smith) 
1 (User Jane) 
1 (User Jack) 



There can be a large number of agent objects but a much 
smaller number of agent classes. Every agent object has a 
<class name, instance number> as its unique identifier. The 
details are presented here just for information. Chentsdo not 
have to know anything about these details. 
HTTP Server Liaison (HSL) Component 302 

The primary goal of the HSL component 302 is to 
communicate with the HTTP server. It understands HTML, 
NSAPI issues, agent home page, etc. The HSL 302 provides 
the various UI related stuff to create agents using a Web 
browser. It is responsible for accepting the HTTP input and 
parsing it into appropriate arguments which are then passed 
to the AC 305. All UI and server related issues from the AC 
305 are thereby isolated. It is a direct application of the 
Model-View-Controller (MVC) paradigm. 

HSL 302 also enforces some preliminary access control 
issues. The HSL 302 can check if the user is authorized to 
access agent services based on the request coming in. Note 
that, in case of some servers, the HSL component 302 may 
not exist. 
Agent Store 310 

The Agent Store 310 is an internal component of the agent 
subsystem 311 not visible to public clients. It manages all 
persistent storage issues (BTree, Database, etc.). The AC 
305 uses the Agent Store 310. The Agent Admin component 
304 also uses the Agent Store 310. 

The Agent Store 310 uses two levels of storage. The 
primary store is a flat file, ahnost fully recoverable. It stores 
agent objects sequentially. This is replaced by a true data- 
base when a database is used with every server. 

The primary store is accessed using a hash table for speed. 
If the hash table is damaged, it will be discarded and a new 
one will be buih using the primary store. 
Event Processor (EP) 306 

The EP component 306 manages event detection and 
triggering of agents. The potential set of events that can 
trigger an agent can be large. The agent subsystem 310 
should not be limited by the event types that it understands. 
It should be possible for server/application developers to 
define new event types that trigger agents. To achieve this 
goal, event detection and triggering is delegated to the EP 
component 306. 

The AC 305 does not attach any meaning to different 
event types. The EP 306 is responsible for understanding 
different event types, registering for them, detecting them, 
and finally triggering agents. Any event associated data 
passed to the AC 305 is passed on to the EP 306 transpar- 
ently without any processing within the AC 305. 



Only the AC 305 and the Agent Admin 304 components 
communicate with the EP 306. When the EP 306 detects an 
event, it calls the trigger fanciiuu exported by the AC 305. 
The problem of handling multiple agents (potentially 
5 thousands) waiting on the same event is handled by the AC 
305. 

The EP 306 can be used for detecting document events as 
well as time triggered events within a HTTP server. Other 
servers can provide their own event processors and the agent 
10 controller will work with them without any problems. 

The EP 306 need not provide agent registration/ 
maintenance (for events) across server runs. It should only 
be capable of storing necessary information persistently 
during a server run. This is because, when the agent sub- 
is system is initialized, the AC 305 will initiate the registration 
of all agent objects in the agent store with the EP 306 (AC 
305 is responsible for persistency of agent objects). 
However, implementers of new EPs are free to adopt their 
own schemes. 

20 The EP 306 also supports some admin features which are 
mostly used by the AC 305 and the Agent Admin 304 
components. 

The EP 306 and AC 305 communicate using event 
handles. When a new agent creation request is submitted to 
the AC 305, it calls on the EP 306 to process the event 
registration (if needed). The EP 306 returns an event handle 
to the AC 305. This event handle is used by the AC 305 to 
manage agent objects waiting on the same event (in the 
simplest case, the event handle could be a string of the 
format "http://warp.foo.htm+105"). It is the responsibility of 
the EP 306 to detect if there is already an agent object 
registered for an event, and avoid multiple registrations. 
This should be quite straight forward. 
Steps in Creating an Agent Object 

When a client request to create an agent object is received 
by the AC 305: 

1. AC 305 passes the event information to the EP 306. 

2. EP 306 builds the event handle using the event type and 
looks it up in its database to check if it has been already 
registered with the message handler. 

3. If (2) is true, then the EP 306 just returns the event 
handle associated with this event to the AC 305. 

4. If (2) is false, the EP 306 registers with the message 
handler for notifications on the event and then returns 
the event handle to AC 305. 

5. AC 305 generates a new agent id for this agent object. 

6. AC 305 uses the event handle to locate the list of agent 
objects (if any) queued on this event handle and adds 
the new agent object to the list and updates the agent 
store. 

7. Finally, AC 305 returns the agent id to the client. 

8. In case of agents submitted by clients using a web 
browser, post the information about this new agent 

55 object to the client. This will be done by the HTTP 
Server Liaison 302. 
Action Processor (AP) 308 

The AP 308 component is responsible for performing the 
necessary actions (send mail, POST to a page, run a 
60 program) when an agent is triggered. It is a simple compo- 
nent that understands different action types and knows how 
to perform the action. 

As with event types, the AC 305 does not process action 
type information, even though it stores them. All data related 
65 to the action(s) of an agent are passed to the AP 308 when 
an agent is triggered. The AP component 308 can also be 
supplied by server/application writers. One implementation 
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maintains a queue of all triggered agents and executes their 
actions sequentially, and informs the AC 305 when it is done 
processing (for every agent). 

The relation between the AP 308 and AC 305 is a 
producer-consumer relation; the AC 305 produces triggered 5 
agents and the AP 308 consumes them. The execution of the 
AP 308 is independent of the execution of the EP 306 and 
AC 305. 

The AP 308 must be very careful with security and access 
control issues. This is tricky with JavaScript actions. 

The AP 308 can impose hmits on what can be done on 
behalf of an agent. For example, it might restrict a JavaScript 
action to execute for only 2 seconds. All such decisions are 
left to the AP implementor. 

The queue of triggered (but not processed) agents in the 
AP 308 need not be persistent across server runs. In case -^^ 
some actions are lost due to a server crash, the AC 308 can 
always restart its actions when the server is re -started. 
Again, implementers of other APs are not bound by this 
policy. It just makes it easier to do this way. 
Steps in Agent Triggering and Action Processing 

When an event is generated: 

1. The EP*s 306 internal callback function is called. The 
EP 306 now maps the event to the appropriate event 
handle it had generated. 

2. EP 306 calls the trigger function of the AC 305 with this 
event handle. 

3. The AC 305 uses the event handle to locate all the agent 
objects waiting on this event. 

4. AC 305 collects all the actions that need to be executed 3Q 
and passes the list of actions (along with the event 
information) to the AP 308 in one call. 

5. AP 308 stores the actions for processing and returns 
control to AC 305 immediately. 

6. AP 308 processes the action list and informs the AC 305 35 
when it has completed processing. 

7. AC 305 updates the trigger statistics of the agent 
objects. 

The action list can be passed to the AP 308 in memory, 
which would be released by AP 308 when it is done 40 
processing the actions. It is also conceivable that the actions 
are passed in a temporary file (when the list of actions is very 
large) which gets deleted when processing is done. The AC 
305 is free to use any of these schemes depending on the 
situation. This is an internal protocol between the AP 308 4S 
and the AC 305. 
Agent Logger 307 

The Agent Lx>gger component 307 is responsible for 
logging all necessary information to an external log file. It 
provides a very simple API and other components call on it 50 
with the necessary information to log as and when needed. 
Agent Admin 304 

The Agent Admin component 304 provides administra- 
tion facilities to the agent subsystem. It allows administra- 
tors and normal users to query and retrieve (subject to ACL) 55 
information about specific agents as well as groups of 
agents. 

The Agent Admin component 304 also allows admins to 
enable and disable agent services (using the Ac 305). Most 
of the work that is done in the Agent Admin 304 depends on 60 
the Agent Store 310. 
Agent Access Controller 309 

The Agent Access Controller 309 takes care of vahdating 
ACLs for any operation performed by clients. It ;is respon- 
sible for maintaining ACLs and such to vaUdate access. 65 

Although the invention is described herein with reference 
to the preferred embodiment, one skilled in the art will 
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readily appreciate that other applications may be substituted 
for those set forth herein without departing from the spirit 
and scope of the present invention. Accordingly, the inven- 
tion should only be limited by the Claims included below. 
What is claimed is: 

1. A process for asynchronous server-client transactions 
across a computer network in a computer environment, 
comprising the steps of: 

providing agent means placed on said server for moni- 
toring specific event(s) on said server; 

wherein when said event(s) occurs, said agent means 
performs a set action or actions in response to said 
event; 

providing agent templates that are the pre-defined set of 
agent types supported by said server; and 

wherein said server publishes said agent templates and 
events available on said server on an agent home page. 

2. The process of claim 1, wherein said action or actions 
are pre-defined by said client. 

3. The process of claim 1, wherein said agent means are 
placed on said server by said chent and require no further 
intervention of said client. 

4. The process of claim 1, wherein said agent means are 
created by a news reader and are treated as a value added 
service provided by the application, and wherein said agents 
means is then sent to said server upon said client's approval. 

5- The process of claim 1, wherein said agent means 
monitors only the type of events specified by said server. 

6. The process of claim 1, wherein said agent means 
perform actions that include the execution of Java and/or 
Javascript programs. 

7. The process of claim 6, wherein said Java and/or 
Javascript programs are supplied by the client. 

8. The process of claim 6, wherein said Java and/or 
Javascript programs are supplied by the server. 

9. The process of claim 1, wherein said agent means are 
subject to the same access control security restrictions as the 
client that created said agent means. 

10. The process of claim 1, further comprising the step of: 
sending an e-mail notification fi-om said server to said 

client, confirming that said agent means were received; 
and 

wherein said email notification can also be specified to be 
sent to a group of clients. 

11. The process of claim 1, further comprising the step of: 
sending an e-mail notification firom said server to said 

client, notifying said client that an agent means has 
expired. 

12. The process of claim 1, wherein clients select from the 
Ust of agent types available on said server and submit an 
agent to said server. 

13. The process of claim 1, further comprising the step of: 
providing administration means for allowing said client to 

monitor and manage said agent means. 

14. The process of claim 1, wherein said server assigns a 
unique identifier to each agent means. 

15. The process of claim 1, wherein said agent means is 
assigned a unique token identifier. 

16. The process of claim 1, wherein said client names said 
agent means. 

17. The process of claim 1, further comprising the step of: 
providing server administration means for allowing server 

administrators to maintain and manage agent means 
resident on that server. 
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18. The process of claim 1, further comprising the step of: 
providing agent object creation means for creating agent 

objects ou said server. 

19. The process of claim 1, further comprising the step of; 
providing agent triggering means for mapping the agent 

means to the proper event and triggering upon occur- 
rence of said event. 

20. The process of claim 1, further comprising the step of: 
providing agent processing means for processing the 

action list for an agent means. 

21. The process of claim 1, further comprising the step of: 
providing agent logging means for logging agent infor- 
mation and statistics. 

22. An apparatus for asynchronous server-client transac- 
tions across a computer network in a computer environment, 
comprising: 

agent means placed on said server for monitoring specific 

event(s) on said server; 
wherein when said event(s) occurs, said agent means 

performs a set action or actions in response to said 

event; 

agent templates that are the pre-defined set of agent types 
supported by said server; and 

wherein said server publishes the different agent tem- 
plates and events available on said server on an agent 
home page. 

23. The apparatus of claim 22, wherein said action or 
actions are pre-defined by said client. 

24. The apparatus of claim 22, wherein said agent means 
are placed on said server by said client and require no further 
intervention of said client. 

25. The apparatus of claim 22, wherein said agent means 
are created by a news reader and are treated as a value added 
service provided by the application, and wherein said agents 
means is then sent to said server upon said client's approval. 

26. The apparatus of claim 22, wherein said agent means 
monitors only the type of events specified by said server. 

27. The apparatus of claim 22, wherein said agent means 
perform actions that include the execution of Java and/or 
Javascript programs. 

28. llie apparatus of claim 27, wherein said Java and/or 
Javascript programs are supplied by the client. 

29. The apparatus of claim 27, wherein said Java and/or 
Javascript programs are supplied by the server. 

30. The apparatus of claim 22, wherein said agent means 
are subject to the same access control security restrictions as 
the client that created said agent means. 

31. The apparatus of claim 22, further comprising: 

a module for sending an e-mail notification from said 
server to said client, confirming that said agent means 
were received; and 

wherein said email notification can also be specified to be 
sent to a group of clients. 

32. The apparatus of claim 22, further comprising: 

a module for sending an e-mail notification from said 
server to said client, notifying said client that an agent 
means has expired. 

33. The apparatus of claim 22, wherein clients select from 
the list of agent types available on said server and submit an 
agent to said server. 

34. The apparatus of claim 22, further comprising: 
administration means for allowing said client to monitor 

and manage said agent means. 

35. The apparatus of claim 22, wherein said server assigns 
a unique identifier to each agent means. 
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36. The apparatus of claim 22, wherein said agent means 
is assigned a unique token identifier. 

37. Tne apparatus of claim 22, wherein said client names 
said agent means. 

5 38. The apparatus of claim 22, further comprising: 

server administration means for allowing server admin- 
istrators to maintain and manage agent means resident 
on that server. 

39. The apparatus of claim 22, further comprising: 
agent object creation means for creating agent objects on 

said server. 

40. The apparatus of claim 22, further comprising: 
agent triggering means for mapping the agent means to 

^5 the proper event and triggering upon occurrence of said 
event, 

41. The apparatus of claim 22, further comprising: 

agent processing means for processing the action list for 
2Q an agent means. 

42. The apparatus of claim 22, further comprising: 
agent logging means for logging agent information and 

statistics. 

43. A program storage medium readable by a computer, 
25 tangibly embodying a program of instructions executable by 

the computer to perform method steps for asynchronous 
serve r-chent transactions across a computer network in a 
computer environment, comprising the steps of: 

providing agent means placed on said server for moni- 
30 toring specific event(s) on said server; 

wherein when said event(s) occurs, said agent means 
performs a set action or actions in response to said 
event; 

providing agent templates that are the pre-defined set of 
agent types supported by said server; and 

wherein said server publishes the different agent tem- 
plates and events available on said server on an agent 
home page. 

44. The method of claim 43, wherein said action or 
actions are pre-defined by said client. 

45. The method of claim 43, wherein said agent means are 
placed on said server by said client and require no further 
intervention of said client. 

46. The method of claim 43, wherein said agent means are 
created by a news reader and are treated as a value added 
service provided by the application, and wherein said agents 
means is then sent to said server upon said client's approval. 

47. The method of claim 43, wherein said agent means 
monitors only the type of events specified by said server. 

48. The method of claim 43, wherein said agent means 
perform actions that include the execution of Java and/or 
Javascript programs. 

49. The method of claim 48, wherein said Java and/or 
Javascript programs are supplied by the client. 

50. The method of claim 48, wherein said Java and/or 
Javascript programs are supplied by the server. 

51. The method of claim 43, wherein said agent means are 
subject to the same access control security restrictions as the 
client that created said agent means. 

52. The method of claim 43, further comprising the step 

of: 

sending an e-mail notification from said server to said 
client, confirming that said agent means were received; 
65 and 

wherein said email notification can also be specified to be 
sent to a group of clients. 
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53. The method of claim 43, further comprising the step 

of: 

sending an e-mail notificatioa from said ser\'er to said 
client, notifying said client that an agent means has 
expired, 

54. The method of claim 43, wherein clients select from 
the list of agent types available on said server and submit an 
agent to said server. 

55. The method of claim 43, further comprising the step 

of: 

providing administration means for allowing said client to 
monitor and manage said agent means, 

56. The method of claim 43, wherein said server assigns 
a unique identifier to each agent means. 

57. The method of claim 43, wherein said agent means is 
assigned a unique token identifier. 

58. The method of claim 43, wherein said client names 
said agent means, 

59. The method of claim 43, further comprising the step 

of: 
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providing server administration means for allowing server 
administrators to maintain and manage agent means 
resident on that server. 

60. The method of claim 43, further comprising the step 

5 . . 

providing agent object creation means for creating agent 
objects on said server. 

61. The method of claim 43, further comprising the step 

of: 

providing agent triggering means for mapping the agent 
10 means to the proper event and triggering upon occur- 
rence of said event, 

62. The method of claim 43, further comprising the step 
of: ' 

providing agent processing means for processing the 
J J action list for an agent means, 

63. The method of claim 43, further comprising the step 

of: 

providing agent logging means for logging agent infor- 
mation and statistics. 

* * * * * 
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